Subject: DLSw MIB Comment

From: Brian Jewell <[email-masked]>
Date: Tue, 20 Jun 1995 13:55:12 -0700 (PDT)

Everyone,

After receiving such an overwhelming response to my last EMAIL regarding the
size of rows in the dlswTConnOperTabletable  ;-) , I thought I would submit another
item for consideration by the DLSw MIB SIG...

In some of the tables in the DLSw MIB, there is this reocurring notion of using 
rows to maintain a "history" of past events. For example, the DESCRIPTION for the
dlswCircuitTable states that the table can be used to maintain "causes of dis-
connection" of circuits that are no longer there.

My question is this: Is this a valid use of the concept of MIB tables??

This information can be passed to a management station via a "trap" when such an
event occurs.

But then this raises the point: what if no management stations happen to be
"listening" and the trap is missed? 

Most systems that I am aware of maintain some type of "event log" (syslog, 
or whatever) which is used for the function of saving historical information 
about significant events. It seems to me that this is a more appropriate mechanism
to be used for obtaining information after-the-fact.

The issue of using MIB tables to maintain a history should be of greater
concern to vendors who are actually developing DLSw implementations... Protocol
stacks typically create control blocks (of various types) then discard them when
they are no longer needed (like when a circuit disappears). Consider the
implications of keeping these control blocks around to maintain information
that is no longer needed just to satisfy the requirements of the DLSw MIB: How 
many do I keep? When should they be re-used as opposed to allocating a new one?

I would be interested in knowing if anyone can provide examples of other MIBs
which support the notion of using MIB tables for "remembering" old information.
if there is no precedence for this, my vote is to remove this concept from the 
DLSw MIB.

Thanks.

Brian Jewell
3Com, Inc.